3.9.3 : Back-En inaccessible

[dionee]

Bonjour

Pour effectuer ma migration de Joomla 3.4.8 vers la derniere version, j'ai créé un sous-domaine chez mon hébergeur pour avoir 2 plateformes distinctes et ne pas casser mon site de Production.
Le soucis est que, manifestement, la BD est restée commune....

Dans mon domaine de Test, je suis passé en 3.6.5, sans problème.
Puis, je suis passé en 3.9.3 et l'install a crashé. J'ai eu l'erreur 1054.
Je n'ai plus accès au backen de la Recette, mais le Front End, Poduction et Tests reste accessible.
Le BackEnd Production reste accessible.

J'en ai profité pour voir la Gestion des BD depuis ma Production et j'ai eu ces messages (là que j'ai vu que la BDD est commune >_<) :






http://<site_Recette>/administrator/index.php?option=com_installer&view=database me redirige vers le backend vide

Est-ce que j'ai la possibilité de faire un correctif plus chirurgical ?
Pour éviter ce désagrément, est-ce que je dois passer par une version intermédiaire ?

D'avance, je vous remercie
Dionee

[RobertG]

Bonjour,

Pour corriger la base de données, tu peux utiliser ce script : https://gist.github.com/mbabker/d7bf...5a733607f89281

[dionee]

Je présume que ma version de PHP est trop ancienne ? J'ai la 5.6

Warning: require_once(/home/<...>/migration/includes/helper.php): failed to open stream: No such file or directory in /home/<...>/migration/postupdate.php on line 38

Fatal error: require_once(): Failed opening required '/home/<....>/migration/includes/helper.php' (include_path='.:/usr/local/php5.6/lib/php') in /home/<...>/migration/postupdate.php on line 38

[RobertG]

Normalement non, PHP 5.3.10 est le minimum pour les versions récentes de Joomla!
Seule une extension pourrait exiger plus récent.

Peux-tu passer en 7.1 seulement pour ce site de test ?

Ce qui m'inquiète, indépendamment de cette erreur, c'est ton rappel du fait que c'est la même base pour le site de test et celui de production : as-tu bien changé le préfixe des tables lorsque tu as cloné le site ?

[dionee]

Bonjour
Le drame est, après relecture ce que j'ai fait, que je n'ai pas changé le préfixe des tables ... >_<
Je ne suis pas allé plus loin. Ma prochaine manip est de réinstaller le backup de mon site initial sur le clone, avec les mêmes préfixes pour revenir à l'état initial.

On est bien d'accord que changer les préfixes des tables me permet d'avoir une autre BDD virtuelle ?

J'avais tester le 7.1 il y a quelques temps, mais j'avais eu un message d'erreur. Je ne m'y étais pas plus attarder, la MAJ de Joomla étant + prioritaire

[manu93fr]

Bonjour,
la réponse est OUI

Quand tu restaure une copie de ton site sur le même hébergement en sous domaine, l'idéal est d'avoir une base de donnée COMPLETEMENT indépendante de celle du site de production ... pour ne pas se mélanger les pinceaux et planter le site de production
Et si tu n'as qu'une seule base de donnée, alors tu dois ABSOLUMENT changer de préfixe de tables car sinon, les deux sites (production ET sous domaine) utilisent les mêmes tables de ta base de donnée unique ... donc quand tu travailleras sur la copie du site en sous domaine .... tu agiras AUSSI sur le site de prod et ça peut vite planter le site de production puisque lui est resté sur une version antérieur mais communique avec une base de donnée qui évolue sur une version actuelle !

[dionee]

Merci Manu93, cela confirme mon analyse >_<

Je suis revenu en arrière en installant sur mon sous-domaine clone le back-up que j'avais fait du site de Prod juste avant les opérations.
Tout à l'air d'être revenu dans l'ordre sauf ceci :


Dans "Autres informations" :


Quelle est ma marge de manoeuvre pour corriger ces champs vides ?
Je présume qu'il ne faut pas tenter quelconque MAJ avant d'avoir fixé tout cela ?

Merci de votre aide
Dionee

[manu93fr]

Si tu es sur d'être a 100% isolé de ton site de production (surtout la base de donné) ... tu as un bouton [correction] en haut a gauche ... tu clique dessus pour que Joomla mette a jour sa base de donnée tout seul comme un grand

[dionee]

Effectivement

Merci à tous pour votre aide

Je vais continuer le processus, cette fois, en renommant correctement les préfixes des tables .....

[Eddy.vh]

Bonjour.

As-tu également ces messages sur le site de prod ?

[dionee]

Bonjour

La Production est redevenue d'aplomb. Je l'ai corrigée et tout est rentré dans l'ordre concernant la BD

[dionee]

J'ai refait une installation du site sur le sous-domaine en prenant soin, cette fois, de changer, le préfixe des tables de BD.
J'ai eu une collection d'erreur BD qui a été corrigé automatiquement dans Gestion / Base de données.

Par contre, j'en ai 9 qui sont incorrigibles : j'ai beau demander la correction, elles restent ....

mod666_ étant le nouveau préfixe.

Concernant la Prod, pas d'erreur BD et un site qui tourne correctement

[Eddy.vh]

Refais un backup Akeeba du site de prod. Supprime les fichiers du sous-domaine et les tables de ce même sous-domaine.
Restaures-y ton backup frais avec Akeeba kickstart en prenant soin de créer préalablement une nouvelle base de données si la précédente était partagée.

[dionee]

= repartir d'une base from scrach ?

[RobertG]

Ce qu'Eddy propose, c'est réinstaller sur une nouvelle base pour bien séparer de la base actuelle, si je comprends bien.

Mais ce qui m'inquiète, c'est qu'en utilisant les mêmes tables sur le site de production et son clone, tu as mis à jour les tables pour les deux sites, dont celui de production qui se retrouve avec des tables dans une version différente de celle des fichiers.